contents

Git 전략은 종종 브랜칭 모델 또는 워크플로우라고 불리며, 개발팀이 브랜치를 생성, 관리, 병합하기 위해 따르기로 합의한 규칙과 관례의 집합입니다. 일관된 전략을 갖는 것은 협업에 매우 중요하며, 이는 혼란을 방지하고, 깨끗하고 이해하기 쉬운 프로젝트 히스토리를 보장하며, 안정적인 코드베이스를 유지하는 데 도움이 됩니다.

모든 경우에 맞는 "최고의" 전략은 없으며, 올바른 전략은 팀의 규모, 프로젝트 유형, 릴리즈 일정에 따라 달라집니다.

1. GitFlow 📜

GitFlow는 매우 구조화되고 규칙이 명확한 브랜칭 모델입니다. 가장 오래되고 잘 알려진 전략 중 하나로, 정기적이고 버전이 명시된 릴리즈가 있는 프로젝트를 위해 설계되었습니다.

핵심 아이디어: 개발의 여러 단계를 위한 특정 장기 브랜치와 기능, 핫픽스, 릴리즈를 위한 단기 브랜치를 사용합니다.

브랜치 구성:

• 장기 브랜치 (Long-Lived Branches):

  • master (또는 main): 운영 환경의 기준이 되는 브랜치입니다. 안정적인 릴리즈 버전만 포함하며, 각 커밋에는 버전 번호(예: v1.0.1)가 태그로 지정됩니다.

  • develop: 진행 중인 개발을 위한 주 통합 브랜치입니다. 모든 새로운 기능은 develop으로 병합됩니다.

• 지원 브랜치 (Short-Lived):

  • feature/*: 새로운 기능을 개발하기 위한 브랜치입니다. develop에서 분기하여 다시 develop으로 병합됩니다.

  • release/*: 새로운 프로덕션 릴리즈를 준비하기 위한 브랜치입니다. develop에서 분기합니다. 최종 버그 수정과 테스트가 여기서 이루어집니다. 준비가 되면 이 브랜치는 master(릴리즈 생성)와 develop(버그 수정이 유실되지 않도록) 양쪽에 병합됩니다.

  • hotfix/*: 운영 환경의 긴급한 버그를 수정하기 위한 브랜치입니다. master에서 분기하여 수정 후, master와 develop 양쪽에 다시 병합됩니다.

• 적합한 환경:

  • 명시적인 버전 번호가 있는 전통적인 소프트웨어 (예: 데스크톱 애플리케이션, 모바일 앱).

  • 운영 환경에서 여러 버전을 지원해야 하는 프로젝트.

• 단점:

  • 지속적 배포를 하는 현대적인 웹 애플리케이션에는 지나치게 복잡하고 형식적일 수 있습니다.

2. GitHub Flow 🚀

GitHub Flow는 GitHub에 의해 대중화된 가볍고, 단순하며, 효과적인 전략입니다. 지속적 통합 및 지속적 배포(CI/CD) 개념을 중심으로 설계되었습니다.

핵심 아이디어: main 브랜치는 항상 안정적이고 배포 가능해야 한다. 모든 개발은 기능 브랜치에서 이루어진다.

브랜치 구성:

• main: 단일 주요 브랜치. main에 병합된 모든 것은 안정적인 것으로 간주되며 즉시 운영 환경에 배포되어야 합니다.

• feature/* (또는 설명적인 이름): 기능 및 버그 수정을 포함한 모든 새로운 작업을 위한 브랜치입니다. main에서 분기하여 다시 main으로 병합됩니다.

워크플로우:

1. main에서 설명적인 이름의 브랜치를 생성합니다 (예: add-user-authentication).

2. 이 브랜치에 작업을 커밋합니다.

3. 작업이 검토 준비가 되면 **풀 리퀘스트(Pull Request, PR)**를 엽니다.

4. 팀이 코드를 검토하고, 변경 사항에 대해 논의하며, 자동화된 테스트를 통해 안정성을 검증합니다.

5. PR이 승인되면 main으로 병합됩니다.

6. 업데이트된 main 브랜치는 자동으로 운영 환경에 배포됩니다.

• 적합한 환경:

  • 대부분의 웹 애플리케이션 및 지속적 배포를 실천하는 프로젝트.

  • 단순하고 빠른 속도의 워크플로우를 원하는 팀.

• 단점:

  • 명시적인 버전 릴리즈를 관리하거나 운영 환경에서 여러 버전을 지원하는 데는 이상적이지 않습니다.

3. GitLab Flow

GitLab Flow는 GitHub Flow를 좀 더 구조화한 확장 버전입니다. 다른 환경과 릴리즈를 처리하기 위해 추가적인 브랜치를 두어, 단순한 "main에 병합하고 배포" 모델보다 더 많은 제어를 제공합니다.

핵심 아이디어: GitHub Flow와 동일하지만, 추가적인 장기 환경 브랜치를 둡니다.

브랜치 구성:

• main: 주 개발 브랜치이지만, 운영 환경에 직접 배포되지는 않습니다.

• feature/*: 새로운 작업을 위해 main에서 분기합니다.

• pre-production, production: 배포 환경에 해당하는 장기 브랜치입니다.

워크플로우:

1. 기능 브랜치 워크플로우는 GitHub Flow와 동일합니다 (main에서 분기, PR, main으로 병합).

2. main이 릴리즈 준비가 되면, pre-production 브랜치로 병합되고, 이는 최종 테스트를 위해 스테이징 환경으로의 배포를 트리거합니다.

3. 검증이 완료되면, pre-production 브랜치는 production 브랜치로 병합되어 실제 서버로의 최종 배포를 트리거합니다.

• 적합한 환경:

  • 운영 릴리즈 전에 스테이징, 프리-프로덕션 또는 다른 테스트 환경이 필요한 프로젝트.

  • 정해진 릴리즈 주기가 있는 프로젝트 (예: "하루에 한 번 배포").

• 단점:

  • GitHub Flow보다 약간 더 복잡합니다.

4. 트렁크 기반 개발 (TBD) 🌳

트렁크 기반 개발(Trunk-Based Development)은 구글이나 메타와 같은 최고의 기술 기업에서 사용하는 고속 전략입니다. 브랜치를 극도로 짧게 유지하고 코드를 가능한 한 자주 주 브랜치에 통합하는 것을 강조합니다.

핵심 아이디어: 모든 개발자는 "트렁크"라고 불리는 단일 주 브랜치(main)에서 작업합니다.

워크플로우:

• 개발자들은 몇 시간 또는 최대 며칠 동안만 유지되는 매우 짧은 수명의 브랜치를 만듭니다.

• 또는 일부 팀은 작은 변경 사항을 main 트렁크에 직접 커밋하기도 합니다.

• 코드는 하루에 여러 번 트렁크에 병합됩니다.

• 피처 플래그 (또는 토글): 이것이 TBD를 가능하게 하는 핵심입니다. 미완성이거나 아직 릴리즈되지 않은 기능은 코드 내에서 피처 플래그로 감싸집니다. 이를 통해 코드는 병합되어 운영 환경에 배포될 수 있지만, 기능이 완성되고 플래그가 켜질 때까지 사용자에게는 보이지 않게 할 수 있습니다.

• 적합한 환경:

  • 매우 성숙한 CI/CD 및 자동화된 테스트 문화를 가진 크고 숙련된 팀.

  • 매우 빠른 통합 및 배포 속도가 필요한 프로젝트.

• 단점:

  • 높은 수준의 개발자 규율과 견고한 자동화 테스트가 필요합니다. 트렁크가 깨지면 전체 팀이 막힐 수 있습니다. 초보자에게는 권장되지 않습니다.

전략 요약

references